This document discusses the benefits of test-driven development (TDD) and addresses common objections to TDD. It begins by joking that legendary martial artist Chuck Norris does not need unit tests because his code is flawless. However, it acknowledges that most developers are not Chuck Norris and do need unit tests. The document then provides an overview of TDD basics like the "red-green-refactor" process. It emphasizes that tests should focus on executable requirements and user stories. The document concludes by acknowledging that TDD requires practice but can help developers write higher quality code with more confidence.

1. Real Developers Don’t Need Unit Tests
Mythbusting TDD

2. So who is this guy, anyway?
John Ferguson Smart
CEO Wakaleo Consulting
Consultant, Trainer, Mentor, Author,...

3. So who is this guy, anyway?
John Ferguson Smart
CEO Wakaleo Consulting
Consultant, Trainer, Mentor, Author,...

4. So who is this guy, anyway?
Java Power Tools Bootcamp
maven Hudson
JUnit
London
January 24-28 2011

5. Introduction
Real Developers Don’t Need Unit Tests
Bugs?
Chuck Norris’s code doesn’t have bugs
His code always work. ALWAYS.

6. Introduction
Real Developers Don’t Need Unit Tests
Bugs?
Emergent design?
Chuck Norris’s code is perfectly
designed the first time round
His favorite design pattern is the
Roundhouse Kick

7. Introduction
Real Developers Don’t Need Unit Tests
Bugs?
Emergent design?
Technical documentation?
Chuck Norris doesn’t need
technical documentation
He just stares down the code until it
tells him everything he wants to know

8. Introduction
Real Developers Don’t Need Unit Tests
Bugs?
Emergent design?
Technical documentation?
Executable requirements?
Chuck Norris doesn’t need
requirements to be executable
He can execute whatever he wants

9. Introduction
Real Developers Don’t Need Unit Tests
Bugs?
Emergent design?
Technical documentation?
Executable requirements?
Acceptance Tests?
Chuck Norris doesn’t need
acceptance tests
Everything Chuck does is acceptable

10. Introduction
Real Developers Don’t Need Unit Tests
OK, so Chuck Norris doesn’t need Unit Tests
But what about the rest of us?

11. TDD Basics
TDD is not about writing tests
So what is this TDD thing, anyway?

12. TDD Basics
TDD in a nutshell...
“Red...Green...Refactor”

13. TDD Basics
TDD in a nutshell...
“The code your code could smell like”

14. TDD Basics
TDD in a nutshell...
Always tidy up after you play...

15. Stay On Target
Stay focused on the requirements
User Story 1 - Transfer funds
As a bank client
I want to withdraw funds from my current account
So that I can buy beer
User Story 1 - Acceptance Tests
- Cash withdrawal should deduct sum from balance
- Client cannot withdraw if insufficient funds
- Client cannot withdraw if account blocked
...
@Test
public void aCashWithdrawalShouldDeductSumFromBalance() {
Account account = new Account();
account.makeDeposit(100);
account.makeCashWithdraw(60);
assertThat(account.getBalance(), is(40));
}

16. Executable Requirements
Good tests are ‘executable requirements’
User Story 1 - Transfer funds
As a bank client
I want to withdraw funds from my current account
So that I can buy beer
User Story 1 - Acceptance Tests
- Cash withdrawal should deduct sum from balance
- Client cannot withdraw if insufficient funds
- Client cannot withdraw if account blocked
...
@Test
public void aCashWithdrawalShouldDeductSumFromBalance() {
Account account = new Account();
account.makeDeposit(100);
account.makeCashWithdraw(60);
assertThat(account.getBalance(), is(40));
}

17. Know where you’re at
Know what requirements are done
User Story 1 - Transfer funds
As a bank client
I want to withdraw funds from my current account
So that I can buy beer
User Story 1 - Acceptance Tests
- Cash withdrawal should deduct sum from balance
- Client cannot withdraw if insufficient funds
- Client cannot withdraw if account blocked
...

18. Safety net
Refactor with confidence

19. Better-designed code
Testable code is well-designed code

20. Not just for green fields
Improve your legacy code base

21. TDD for unbelievers
So TDD is the answer to all my problems?
No, sorry, TDD is not a Silver Bullet
You still have to use your brain
Also use other design activities (domain modeling, DDD,...)
TDD is not applicable everywhere
Highly visual coding, ‘know it when you see it’ stuff,...
TDD works best if you have a vision

22. TDD for unbelievers
But how can I write tests if I don’t know what the code looks like?
How can you write code when you can’t express what it
should do?
“Write code for others as you would have them write code for you”
- Some agile dude

23. TDD for unbelievers
I don’t have time to write tests
But you have time to fix the code afterwards, right?
“I can get it done much faster if it doesn’t have to work”
- Kent Beck (paraphrased)
New TDDers will take maybe 20-30% longer
Experienced TDD developers don’t spend much (if any)
more time coding
But the code is of much higher quality

24. TDD for unbelievers
But I'm writing more test code than application code!
Sure, writing tests is part of the process
You will write lots of tests...
...but your code will be more focused and more accurate

25. TDD for unbelievers
My tests break whenever I change my code
Try to test the behaviour, not the implementation
Validate behaviour, don’t verify implementation

26. TDD for unbelievers
Our tests are too hard and take too much time to keep up to date
Treat your test code as production code
Be wary of test maintenance overhead
Test code is not second-class code
Refactor to keep your test code maintainable
Avoid technical debt

27. TDD for unbelievers
I found a bug in the production code. TDD doesn’t work.
see “TDD is not a Silver Bullet”
You still need your testers!
You can still make mistakes...
...but they are easier to isolate and to fix
If you find a bug, just add another test to reproduce it, then fix it!

28. TDD for unbelievers
I’ve heard TDD encourages sloppy design. Isn't it better to have a
general vision of the problem before coding the solution?"
Sometimes, yes. That's what the refactoring phase is for.
TDD does not preclude initial high-level design
Brainstorm a high-level design approach
Define a common well-known domain language
Use an ‘Iteration 0’ and spikes
Don’t be afraid to refactor
TDD works better when you have a vision

29. TDD for unbelievers
I use a database/network/web service... and TDD-style unit tests
can't test it. TDD doesn't work
You will need integration tests too
Unit tests when you can, integrations tests when you must
Integration tests for system boundaries
Mock out these boundary classes for the rest of your tests

30. TDD for unbelievers
Our BAs and product owners aren’t buying this TDD stuff
Try putting them into the feedback loop
Acceptance-Test Driven Development is about communication
BDD help BAs and POs participate in writing executable requirements
scenario "A cell with less than 2 live neighbours should die", {
given "Given a cell with no live neighbours",
when "a new generation is generated",
then "that cell will have died"
}

31. TDD for unbelievers
Our BAs and product owners aren’t buying this TDD stuff
Try putting them into the feedback loop
Acceptance-Test Driven Development is about communication
BDD help BAs and POs participate in writing executable requirements
scenario "A cell with less than 2 live neighbours should die", {
given "Given a cell with no live neighbours", {
initialGrid = ""...
.*.
...""
theUniverse = new Universe(seededWith(initialGrid));
}
when "a new generation is generated", {
theUniverse.createNextGeneration()
}
then "that cell will have died", {
theUniverse.grid.shouldBe ""...
...
...""
}
}

32. TDD for unbelievers
Our BAs and product owners aren’t buying this TDD stuff
Try putting them into the feedback loop
Acceptance-Test Driven Development is about communication
BDD help BAs and POs participate in writing executable requirements
Given a living cell with no live neighbours like this
...
.*.
...
When a new generation is generated
then the grid should look like this:
...
...
...

33. TDD for unbelievers
Many BDD tools also have great reporting features
Test results summary
Unimplemented stories
Failed stories

34. TDD for unbelievers
Many BDD tools have great reporting features
Test results summary
Test failure details
Unimplemented stories

35. TDD for unbelievers
“I’ve tried TDD, but I soon lapse back into my old code-first habits”
TDD takes practice and know-how
Unit tests when you can, integrations tests when you must
Learn about TDD - read books on TDD practices
Do pair program with someone who knows TDD
Participate in and organize coding dojos
<blatant plug>Training/mentoring</blatant plug>

36. Conclusion
Real Developers Don’t Need Unit Tests?
So maybe Chuck should be writing
unit tests after all...
I agree. You go talk to him

37. Enjoy your quiche!
John Ferguson Smart
Wakaleo Consulting Ltd.
http://www.wakaleo.com
Email: john.smart@wakaleo.com
Twitter: wakaleo